home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 4 / BBS in a Box - Macintosh - Volume IV (January 1992) (BBS in a Box).iso / Files / Word / D / DIGEST V5-52 < prev    next >
Encoding:
Text File  |  1987-05-25  |  20.8 KB  |  470 lines  |  [TEXT/MACA]

  1. Network_Server.Daemon 03/11/87  0430.4 est Wed info-mac
  2. Subject:  INFO-MAC Digest   V5 #63
  3. From: INFO-MAC-Request@SUMEX-AIM.STANFORD.EDU
  4.  
  5.  
  6. INFO-MAC Digest          Tuesday, 10 Mar 1987      Volume 5 : Issue 63
  7.  
  8. Today's Topics:
  9.                    DrawPicture to an Offscreen Bitmap
  10.                            ModalDialog filters
  11.                            Re: Mouse freezes?
  12.                      VBL tasks and ADDQ instructions
  13.                          addq.w to adjust stack
  14.                     Re: addq.w for popping arguments?
  15.                     Re: addq.w for popping arguments?
  16.                             VBL information?
  17.                   LaserWriter and Adobe Version numbers
  18.                     Mac Plus and Hard disk powerdown.
  19.                 Correction to Postings on Script Manager
  20.                         PROTECTING STATIC MEMORY
  21.                              laser spoolers
  22.                         MacNifty Audio Digitizer
  23.              Are there 3rd party color monitors for Mac II?
  24.                   Rerouting default files in Word 3.0?
  25.                       Color printing from MacWrite
  26.  
  27.  
  28. ----------------------------------------------------------------------
  29.  
  30. Date: 10 Mar 1987 16:52-EST
  31. From: Chuck.Weinstock@sei.cmu.edu
  32. Subject: DrawPicture to an Offscreen Bitmap
  33.  
  34. I am trying to draw a picture to a *large* offscreen bitmap using
  35. Lightspeed C.  I believe that the bitmap is set up correctly, using
  36. NewPtr to get the space and setting a boundary rectangle.  rowBytes is
  37. even and appears to be the right value.  After a SetPortBits the
  38. portBits field looks correct.
  39.  
  40. The picture draws correctly to the screen.  When I send it to the
  41. offscreen bitmap DrawPicture loops forever with a trap AXC6, and the
  42. heap is corrupted.
  43.  
  44. Does anyone out there have any idea what is going on?  All I really
  45. want to do is turn a PICT file into a multi-screen bitmap that I can
  46. then manipulate in my real application (like the Thunderscan software
  47. does, only somewhat bigger).  Does anyone have any C code fragments
  48. that will accomplish this for me?
  49.  
  50. Any help would be appreciated.
  51.  
  52. Chuck Weinstock
  53.  
  54. ------------------------------
  55.  
  56. Date: Tue, 10 Mar 87  8:40:06 EST
  57. From: Mike Kraley <kraley@ccw.bbn.com>
  58. Subject: ModalDialog filters
  59.  
  60. FRUIN@HLERUL5.BITNET is having a lot of problem getting a custom
  61. filter function to work in ModalDialog.  This completely threw me
  62. for a loop too - the words in IM are vague and I leaped to
  63. exactly the same wrong conclusion as Mr. Fruin.
  64.  
  65. The bad assumption is that, when the filter function is called,
  66. that the myItem parameter holds the item number where the click
  67. happened.  WRONG!  This function is called for EVERY event that
  68. happens in the dialog window: clicks, keys, etc., and no (or
  69. little) processing is done before the callback.  Only the first
  70. two parameters are set at the call: myDialog and myEvent.  myItem
  71. is probably just garbage.  Your function must parse the raw event
  72. itself and figure out if it's a kind you are interested in.  then
  73. you use the myItem parameter (notice it's a VAR) to pass
  74. information BACK to ModalDialog, i.e.  what item number you would
  75. like it to return to its caller.
  76.  
  77. When you are processing the event, if it is a click, you have to
  78. explicitly figure out which item the click is in, e.g. by doing
  79. PtInRect.  Remember to think about global vs local coords; the
  80. event is global.
  81.  
  82. Good luck.
  83.  
  84. ...Mike
  85.  
  86. ------------------------------
  87.  
  88. Date: Sun, 8 Mar 87 21:39:34 mst
  89. From: dlc@LANL.ARPA (Dale Carstensen)
  90. Subject: Re: Mouse freezes?
  91.  
  92. sbm@Purdue.EDU asked why mouse interrupts aren't being processed when
  93. interrupts are enabled.  Although the processor has interrupts enabled, the
  94. SCC, which handles tracking the mouse, does not have interrupts enabled.
  95. The reason the SCC doesn't have interrupts enabled is because the SCC
  96. received a reset.  The reason it is so likely for the SCC to receive a
  97. reset is that the Macintosh address mapping PALs allow a number of addresses
  98. to access the SCC, somewhere on the order of 4 to 8 million (out of 16
  99. million available addresses).  It's likely you are de-referencing a bad
  100. pointer.
  101.  
  102. ------------------------------
  103.  
  104. Date: Sun, 8 Mar 87 22:48 CDT
  105. From: <MAX%TAMLSR.BITNET@wiscvm.wisc.edu>
  106. Subject: VBL tasks and ADDQ instructions
  107.  
  108. To the person who asked about VBL tasks going away when an application
  109. quits...
  110.  
  111. A VBL task can expire in two ways.  It can be removed explicitly by
  112. a call to VRemove, or its counter can be allowed to decrement to
  113. zero and not be reset.  Thus, VBL tasks are impervious to application
  114. comings and goings.  Of course, this assumes that the task wasn't
  115. placed in the application heap...  If you place a task in the application
  116. heap and don't remove it before quitting, the Vertical Retrace Manager
  117. will try to call the task anyway and crash.
  118.  
  119. To the person complaining about ADDQ.W instructions to pop the stack:
  120.  
  121. An ADDQ instruction operating on an address register (like the
  122. stack pointer) operates on the whole long word regardless of the
  123. operation size.
  124.  
  125. Hope this helps,
  126.  
  127. Greg Marriott
  128. The MacHax(tm) Group
  129. %-b
  130.  
  131. ------------------------------
  132.  
  133. Date: Mon 9 Mar 87 13:20:51-EST
  134. From: Ian Lance Taylor <TAYLOR@XX.LCS.MIT.EDU>
  135. Subject: addq.w to adjust stack
  136.  
  137. This is in reply to the message complaining about the use of addq.w
  138. to remove arguments from the stack. This will actually work fine,
  139. since on the 68000 all address register arithmetic is performed as
  140. longwords; i.e. the immediate operand of the addq will be sign extended
  141. before the addition. Since the stack pointer is just an address register,
  142. addq.w works fine. Of course, the addq.l instruction takes the same number
  143. of bytes, so I have no idea why they didn't use it.
  144.  
  145. Ian Lance Taylor
  146. taylor@xx
  147.  
  148. ------------------------------
  149.  
  150. Date: 9 Mar 1987 18:30-EST
  151. From: Walter.Smith@dba.mach.cs.cmu.edu
  152. Subject: Re: addq.w for popping arguments?
  153.  
  154. Re: Popping arguments with addq.w:
  155. Don't panic.  M68000 Programmer's Reference Manual, 4th Edition, p.61:
  156. "The entire destination address register is used regardless of the
  157. operation size."
  158.  
  159. Re: Debuggers running with interrupts enabled:
  160. Debugging VBL tasks is a very special case, like debugging INITs.
  161. Neither is easy.  Assuming all current VBL tasks work, which is usually
  162. the case, leaving interrupts on allows the mouse to move and the disk
  163. drive to shut off, which is nice.  To debug a VBL task, use Macsbug.
  164. It turns interrupts off, and you can usually survive it long enough to
  165. get the task working and switch to a real debugger.  In some cases, you
  166. could just zero the VBL queue before getting into the section of the
  167. program that is failing.
  168.  
  169.   Walt
  170. wrs@k.cs.cmu.edu    ..!seismo!cmu-cs-k!wrs
  171.  
  172. ------------------------------
  173.  
  174. Date: 10 Mar 1987 08:25-EST
  175. From: Tom.Lane@zog.cs.cmu.edu
  176. Subject: Re: addq.w for popping arguments?
  177.  
  178. >I noticed that Aztec C uses addq.w on the stack pointer to pop
  179. >arguments after function calls.  If I understand addq.w correctly, this has
  180. >obvious drawbacks.  If the stack pointer is on a 64K boundary, addq.w will
  181. >not carry into the high word of SP, and the stack pointer will end up
  182. >pointing into no man's land.
  183.  
  184. Fortunately, you don't understand addq.w.  According to the relevant
  185. page of the 68000 manual, "The entire destination address register is
  186. used regardless of the operation size."  This is an instance of a
  187. general principle that applies throughout the 68K instruction set:
  188. when an address register is the destination, the operation is ALWAYS
  189. a longword (32-bit) operation.  The ".w" or ".l" modifier of the
  190. instruction indicates how wide the SOURCE datum is, but a word source
  191. is sign-extended and used in a long operation with the address
  192. register value.  Thus bugs of the kind you envision can't happen.
  193.  
  194. In other words, addq.w and addq.l are the same if the destination is
  195. an address register (though definitely not if it's a data register).
  196. Personally, I always write "addq.l" in this case when I'm writing
  197. assembly code, just to make things clear.
  198.  
  199. When more than 8 bytes are to be popped, you have to use "adda #n,SP".
  200. In this case the difference between .w and .l is real and useful: .w
  201. implies a 16-bit literal value, .l a 32-bit literal.  When popping
  202. arguments, 16 bits is sufficient, and writing "adda.w #20,SP" saves a
  203. word and a memory cycle.  No bug ensues since the CPU sign-extends the
  204. literal to a long value and does a long addition to SP.  I'd be pretty
  205. upset with a compiler that insisted on using "adda.l", thus wasting
  206. 2 bytes in every procedure exit sequence.
  207.  
  208. In summary, using "adda.w" is the right thing to do; when the value
  209. is small enough to allow "addq", ".l" is preferable on stylistic
  210. grounds, but "addq.w" is not wrong.
  211.  
  212. tom lane
  213.  
  214. ARPA: lane@ZOG.CS.CMU.EDU
  215. UUCP: ...!seismo!zog.cs.cmu.edu!lane
  216. BITNET: lane%zog.cs.cmu.edu@cmuccvma
  217.  
  218. ------------------------------
  219.  
  220. Date: Tue, 10 Mar 87 11:23:25 PST
  221. From: PUGH%CCC.MFENET@nmfecc.arpa
  222. Subject: VBL information?
  223.  
  224. There has been a flurry of requests for VBL information on the net, but no
  225. one has posted any answers.  If there is information passing going on in
  226. the background via private email, may I please request that some of that
  227. info be forwarded to the net as there are more people interested in it than
  228. just the requestor.
  229.  
  230. Thanks,
  231.    Jon
  232.  
  233. ------------------------------
  234.  
  235. Date: Sun, 8 Mar 87 20:36:27 cst
  236. From: rackow@anl-mcs.ARPA (Gene Rackow)
  237. Subject: LaserWriter and Adobe Version numbers
  238.  
  239. Question:  What versions of firmware is in your laserwriter?  I have a
  240. Laserwriter with version 38 and another with version 39.  I hear that
  241. Adobe has version 46 out. Possibly higher.
  242.  
  243. Question2:  What are the MAJOR improvements taking place from version
  244. to version?  I have been told that version 41/42 fixed a bug that
  245. caused the LaserWriter to loose virtual memory on errors.  Try sending
  246. 5 print jobs to the printer, of which the first 4 have errors.  The
  247. fifth, and further, jobs will abort due to a framedevice error.  Power
  248. cycling the printer is the only cure.
  249.  
  250. Question3:  How do we go about getting upgrade roms?
  251.  
  252. Gene Rackow
  253.  
  254. ------------------------------
  255.  
  256. Date: Mon, 9 Mar 87 16:56 CST
  257. From: Dan Stewart <STEWART_SYS%uta.edu@RELAY.CS.NET>
  258. Subject: Mac Plus and Hard disk powerdown.
  259.  
  260. Someone once asked about whether or not a Mac Plus and hard disk
  261. configuration should be powered off after use or just left on.  I don't
  262. think an answer was ever given.  In my case I have a Mac Plus and MacBottom
  263. SCSI-21 and I use it roughly every day.  Is it better to just leave
  264. everything run and turn the Mac's screen down, or powerdown the Mac, but
  265. leave the disk running, OR power everything off??  I guess it depends on
  266. how devastating the on/off action is to the circuitry, but I don't really
  267. have a feel for that.  Any suggestions?
  268.  
  269. Dan Stewart
  270. STEWART_SYS@UTA.EDU
  271.  
  272. ------------------------------
  273.  
  274. Date: Mon, 9 Mar 87 11:48:57 pst
  275. From: apple!jordan@ucbvax.Berkeley.EDU (Jordan Mattson)
  276. Subject: Correction to Postings on Script Manager
  277.  
  278. A corection to my posting on the Script Manager....
  279.  
  280.   I made a big mistake in my posting about the Script Manager.  I stated
  281. that the Script Manager was maintained in ROM on the Macintosh SE and
  282. Macintosh II.  This is wrong.
  283.   The Script Manager is a package that is maintained in RAM (having been
  284. loaded from the System File), and therefore will be available on the
  285. Macintosh 512K, Macintosh 512KE, Macintosh Plus, Macintosh SE, and
  286. Macintosh II when the Universial System Disk ships with the Macintosh II
  287. this Spring.
  288.    I am sorry for any confusion that my mis-information has caused any of
  289. you folks.
  290.  
  291. Jordan Mattson                          UUCP:   ucbvax!mtxinu!apple!jordan
  292. Apple Computer, Inc.                    CSNET:  jordan@apple.CSNET
  293. Tools & Languages Product Management
  294. 20525 Mariani Avenue, MS 27S
  295. Cupertino, CA 95014
  296. 408-973-4601
  297.  
  298. ------------------------------
  299.  
  300. Date: Mon, 09 Mar 1987 16:36 PST
  301. From: GDCWOOD%CALSTATE.BITNET@wiscvm.wisc.edu
  302. Subject: PROTECTING STATIC MEMORY
  303.  
  304.  
  305. We have several Macintoshes located in public computer labs on the
  306. Humboldt State campus.  A problem that is occuring more and more
  307. frequently is the changing of the control panel settings, which will leave
  308. the Macs seemingly inoperable to other users.  For example, a user sets
  309. the control panel setting APPLE TALK to CONNECT and then leaves.  Another user
  310. uses the machine and needs to print to an Image Writer connected to the
  311. printer port, no go, Apple Talk is now using that port.  Most users aren't
  312. aware of the effects this have; hence, it is assumed the machine is damaged.
  313. I agree that the  fix is an easy one; however, the machines are down until
  314. the techs are made aware of it and schedule time to fix the problem.
  315.  
  316. After the long winded intro. here is my question.  Is it possible to protect
  317. the portion of RAM, kept active by the battery, so that control panels changes
  318. cannot effect original settings.  The idea being that the settings could be
  319. set to allow general operation, and be protected from accidental or other
  320. changes.
  321.  
  322. Any information would be greeeeeeatly appreciated.
  323.  
  324. Thanks in advance!
  325.  
  326. Dan Calderwood
  327. GDCWOOD@CALSTATE.BITNET
  328. Humboldt State University
  329.  
  330. ------------------------------
  331.  
  332. Date: Mon, 9 Mar 87 22:05:12 EST
  333. From: jonathan@mitre-gateway.arpa (Jonathan Leblang)
  334. Subject: laser spoolers
  335.  
  336. Does anyone have any experience with any of the software laser spoolers
  337. curreny available?  I am considering purchasing one, and any comments would
  338. be greatly appreciated.
  339.  
  340. FINDER 5.4 TIP
  341. Holding OPTION down while selecting Eject from the file menu ejects the disk
  342. and removes it from the desktop (the same as dragging to the trash).
  343. This only works when selecting from the menu, option-command-E won't do it.
  344.  
  345. jonathan
  346.  
  347. |\  /|  |   |   |  \  |           ARPA: jonathan@bert.mitre.org
  348. | \/ |  |   |   |__/  |__       BITNET: leblangj@vtvax3.bitnet
  349. |    |  |   |   | \   |         MABELL: (703) 883-5761
  350. |    |  |   |   |  \  |___      USNAIL: 7525 Colshire Drive
  351.                                         McLean, VA  22102
  352.   Jonathan A. Leblang
  353.  The MITRE Corporation
  354.  
  355. ------------------------------
  356.  
  357. Date: Mon,  9 Mar 87  16:12:57 AST
  358. From: PAUL%ACADIA.BITNET@wiscvm.wisc.edu
  359. Subject: MacNifty Audio Digitizer
  360.  
  361. I am trying to set up the MacNifty sound digitizer on a Mac Plus and
  362. have been attempting to get the proper cable setup.  I can't see
  363. what's wrong with my setup, but its not working.  This is what I
  364. have at the moment:
  365.  
  366.        DB9                      DIN8
  367. pin 1: Frame ground          to pin 1
  368. pin 2: +5V (from 7805)
  369. pin 3: Signal ground         to pin 4
  370. pin 4: TxD positive          to pin 6
  371. pin 5: TxD negative          to pin 3
  372. pin 6: +12V (from AC adapter)
  373. pin 7: HSC in                to pin 2
  374. pin 8: RxD positive          to pin 8
  375. pin 9: RxD positive          to pin 5
  376.  
  377. Does this look right?  If not, can someone out there tell me what
  378. is right.  Please reply directly.  Thanx.
  379.  
  380.  
  381. UUCP:      {seismo:watmath:utai:garfield}!dalcs!aucs!Paul
  382. BITNET:    {Paul:phs}@Acadia
  383. Internet:  {Paul:phs}%Acadia.BITNET@WISCVM.WISC.EDU
  384.  
  385. ------------------------------
  386.  
  387. Date: Mon, 9 Mar 87 20:42 EDT
  388. From: <KURAS%BCVAX3.BITNET@wiscvm.wisc.edu>
  389. Subject: Are there 3rd party color monitors for Mac II?
  390.  
  391.   We have a Mac II and an SE here at Boston College but Apple has not sent
  392. us a color monitor. The one we have looks as though it was cannibalized
  393. from an old Lisa. Does anyone know whether there are any third party RGB
  394. monitors that can be used as-is with the Mac II and the Apple video card?
  395.   By the way, I understand many of you are upset that there is no upgrade
  396. path from the Plus to the SE, but If you've seen what the inside of the SE
  397. looks like you'd realize why this is impossible. The guts are laid out
  398. completely differently and are packed much more tightly (hence the fan).
  399. The case is also significantly different inside and out. Only the basic
  400. shape remains the same.  It's kinda like the difference brtween the II+ and
  401. the IIe. I hope no one was naive enough to expect an upgrade path to the
  402. II. (Smile...)
  403.   Another thing -- the slot in the SE is being described as a Macitosh SE
  404. expansion slot, so I assume it's different from anything currently
  405. available.
  406.   The II and the SE both look really good. The SE is what the Plus should
  407. have been. (But like all Macintosh products, it's evolutionary. It could
  408. not have been created without its predecessors.) The built-in hard disk is
  409. great. General Computer will have a hard time competing with that. The II
  410. is another story completely. Though I haven't seen color or gray scales
  411. (our video board is beta and has a few bugs) nor have I heard sound (our
  412. unit doesn't have a functioning sound chip) the speed is tremendous. And I
  413. haven't encountered any applications which don't run properly (except an
  414. old version of ResEdit). All in all, it looks like a winner. I'd say Apple
  415. has done themselves proud with this thing.  (And now will come the
  416. inevitable nitpicky complaints of those who refuse to see what a great
  417. product this is and instead look only at the omnipresent defects, always
  418. wanting more and never thankful for what they have.) Sorry. That was just
  419. my Apple-loving inner self speaking. Any questions? Mail me a note.  I'd
  420. also like to hear what others are thinking of this thing.
  421.  
  422. Pat Kuras
  423. Boston College
  424. <KURAS@BCVAX3.BITNET>
  425.  
  426. ------------------------------
  427.  
  428. Date: Mon, 9 Mar 87 11:45 EDT
  429. From: <BELSLEY%BCVAX3.BITNET@wiscvm.wisc.edu>
  430. Subject: Rerouting default files in Word 3.0?
  431.     Is there anyway to reference a specific drive through a file name?  The question arises as follows:  MS Word 3.0 places its default settings file, "Word Settings" in the blessed folder and not on the disk that contains the application "Microsoft Word".  If, then, one uses the system in a RamDisk and MS. Word on another 800K disk, the changes to the default settings file go to the RamDisk and are not automatically saved on a floppy. 
  432.     There is a way around this, but it is not completely satisfactory.  The file name in the code that is relevant to the reading and writing of "Word Settings" occurs on Sectors 31 and 208.  If one wants this file to reside on the program disk, say, "WordDisk", then one can use Fedit to replace these two strings with, say, "WordDisk:defs".  This works fine so long as the overall length of the new name does not exceed that of the original ("Word Settings") and so long as it is terminated in the C-string zero.
  433.     Using the above solution, the default settings file "defs" will not reside on the application disk "WordDisk", and the changes that are made will be saved on this floppy disk rather than in the RamDisk containing the System. 
  434.     The trouble with this solution is that it requires the Word application be particularized to a particular disk name, and it will no longer work correctly if the WordDisk name is changed without similarly altering the Word code. 
  435.     So my question is:  is there some means for indicating, say, the internal drive in the file name that will cause this file always to be read and written to the disk in the internal drive?  I would have thought using the drive number 1, as in "1:DefSettings" would do the trick, but it doesn't.  More generally, is there any way to name a file so that it is directed to the default volume (which is where Word resides) rather than the volume that contains the blessed folder?  This would be ideal since the default settings file would then always exist with the word application regardless of disk name or drive.
  436. My appreciataion in advance for any thoughts and suggestions.
  437. david a. belsley
  438. boston college          belsley@bcvax3.bitnet
  439.  
  440. ------------------------------
  441.  
  442. Date: Tue, 10 Mar 87 14:24:08 PST
  443. From: PUGH%CCC.MFENET@nmfecc.arpa
  444. Subject: Color printing from MacWrite
  445.  
  446. Well, I just had some fun.  I have been playing with my Imagewriter II, which
  447. is a darn nice color printer.  I have used Silicon Press, ColorPrint, and
  448. SuperPaint to do color printing with it and have decided that SuperPaint wins
  449. hands down.  I think I'll just toss out the others.
  450.  
  451. Using SuperPaint's draw layer you can do MacDraw in color and then copy them
  452. into MacWrite documents where they will still print in color!!!!!!
  453.  
  454. That's right, color from MacWrite.  I love it.  Be sure to copy it from the
  455. draw layer though so that it is saved as PICT resources.
  456.  
  457. Jon
  458.  
  459. N         L                          pugh@nmfecc.arpa
  460.  M    A    L          National Magnetic Fusion Energy Computer Center
  461.   F    T    N             Lawrence Livermore National Laboratory
  462.    E         L                       PO Box 5509 L-561
  463.     C                           Livermore, California 94550
  464.      C                                (415) 423-4239
  465.  
  466. ------------------------------
  467.  
  468. End of INFO-MAC Digest
  469. **********************